home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 52 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: alpha.ru.ac.za!cspw
  2. From: cspw@cs.ru.ac.za (Peter Wentworth)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Visual Basic vs. Visual C++
  5. Date: 1 Jan 96 08:44:09 GMT
  6. Organization: Computer Science Department, Rhodes University
  7. Message-ID: <cspw.820485849@alpha>
  8. References: <4bu9ut$6j7@news-srv1.fmr.com>
  9. NNTP-Posting-Host: alpha.ru.ac.za
  10. NNTP-Posting-User: cspw
  11. X-Newsreader: NN version 6.5.0 (NOV)
  12.  
  13. In <4bu9ut$6j7@news-srv1.fmr.com> David Button <David.Button@fmr.com> writes:
  14.  
  15. I think you need to weigh the relative importances of the speed of
  16. the application with your aggressive time frames.  Interpreted languages
  17. are slower, but the overhead price tends to become negligible 
  18. *if* the hard-coded primitives constitute the bulk of the work.
  19. If you're into serious number crunching, sorting, searching, 
  20. or moving graphics about, etc., you'll have to have primitives or 
  21. DLL's (written in C++ or something) for those aspects.  
  22.  
  23. VB is currently (IMO) a cleaner language: you're isolated from the
  24. "assembly level windows API", and won't have to ever see or even
  25. know about windows handles, graphics contexts, etc.  But as another
  26. respondent pointed out, if you want to work at the higher level then
  27. you pay the price of living within the constraints and design framework
  28. which it provides.   If at heart you believe that *real programmers*
  29. write assembler, then Visual C++ will get you right into the mud
  30. of the Windows API.     
  31.  
  32. In some senses, I reckon VB is perhaps a better "glue" for sticking
  33. together existing components.  VC++ is the better tool if most of 
  34. the development is going to be creating new components.
  35.  
  36. I think you could work on more aggressive schedules with VB, but
  37. you'd probably end up with some compromises in your design, and 
  38. a speed disadvantage which may or may not be too serious, depending
  39. on your ration of "glue" to "component building".
  40.  
  41. You probably want to look at Delphi too, since it seems to have 
  42. gone quite a long way towards hiding the horrors of the windows
  43. API and yet it has solved the two-tier problems of VB - having 
  44. to write components in some language other than your glue language.
  45.  
  46. Perhaps someone can venture some opinions about why we cannot get
  47. a Visual C++ that is at least as clean as Delphi?
  48.  
  49. Peter
  50.  
  51.  
  52. >I know I am asking for trouble, but we are undertaking a new project
  53. >with a relatively agressive time frame and we're trying to decide
  54. >whether to program in Visual Basic or Visual C++.  It is a desktop
  55. >application which will typically be running on 486's with 4M-8M of
  56. >memory.  We are primarily concerned with the speed of the application
  57. >(both actual and perceived), availability of competent programmers, 
  58. >and the time to develop (we are under a rather aggressive time
  59. >schedule).  If anyone has read any helpful publications or has 
  60. >performed/seen some benchmark applications, please respond to this
  61. >message.  Any help you can give will be greatly appreciated.
  62.  
  63. >Thanks,
  64. >David Button
  65.  
  66.  
  67. --
  68. EP Wentworth - Dept. of Comp. Sci. - Rhodes University - Grahamstown - RSA.
  69. cspw@cs.ru.ac.za        Knuth's Caveat: "While I have informally proved it,   
  70. fax: +27 461 311915                      I haven't tested it much."
  71.                 
  72.